Implement business activity code to EU from Italy localization by Alexander-Ya · Pull Request #10233 · microsoft/BCApps

Alexander Yakunin (Alexander-Ya) · 2026-08-13T13:35:26Z

What & why

Linked work

Fixes #

How I validated this

I read the full diff and it contains only changes I intended.
I built the affected app(s) locally with no new analyzer warnings.
I ran the change in Business Central and confirmed it behaves as expected.
I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

Risk & compatibility

…Implement-Business-Activity-Code-from-IT

github-actions · 2026-08-13T13:37:03Z

Could not find a linked ADO work item. Please link one by using the pattern 'AB#' followed by the relevant work item number. You may use the 'Fixes' keyword to automatically resolve the work item when the pull request is merged. E.g. 'Fixes AB#1234'

github-actions · 2026-08-13T13:49:06Z

+        BusinessActivityValidator.Validate(Code);
+    end;
+
+    [IntegrationEvent(false, false)]


$\textbf{🟡\ Medium\ Severity\ —\ Events}$

The new integration event OnGetValidator (codeunit "Business Activity Code Mgt.") does not encode its firing position or host routine per the publisher-naming convention, so a subscriber cannot tell from the symbol name where/when it fires relative to Validate(). Consider a position-encoding name such as OnValidateOnBeforeGetBusinessActivityValidator or similar.

Knowledge:

microsoft/knowledge/events/name-events-by-publisher-position.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T13:49:08Z

+
+    fields
+    {
+        field(1; Code; Code[10])


$\textbf{🟠\ High\ Severity\ —\ Privacy}$

New table 395 "Business Activity" declares DataClassification = CustomerContent at table scope but leaves both Normal fields (Code and Description) without their own field-level DataClassification. AS0016 requires the field-level property regardless of the table-level default.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

field(1; Code; Code[10]) { Caption = 'Code'; DataClassification = CustomerContent; NotBlank = true; trigger OnValidate() var BusinessActivityCodeMgt: Codeunit "Business Activity Code Mgt."; begin BusinessActivityCodeMgt.Validate(Code); end; } field(2; Description; Text[100]) { Caption = 'Description'; DataClassification = CustomerContent; }

Knowledge:

microsoft/knowledge/privacy/table-level-data-classification-cascades.md

microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T13:49:09Z

                SetBrandColorValue();
            end;
        }
+        field(395; "Business Activity Code"; Code[10])


$\textbf{🟠\ High\ Severity\ —\ Privacy}$

157 new "Business Activity Code" fields added across changed table/tableextension objects omit an explicit DataClassification (for example Company Information, Purchase Header, Gen. Journal Line). AS0016 requires every Normal field to declare its own DataClassification; relying on the table-level DataClassification leaves these fields effectively unclassified for AppSourceCop/privacy tooling purposes.

Knowledge:

microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md

microsoft/knowledge/privacy/table-level-data-classification-cascades.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T13:49:11Z

+        UpgradeTag.SetUpgradeTag(UpgradeTagDefinitions.GetBusinessActivityCodeUpgradeTag());
+    end;
+
+    local procedure CopyBusinessActivityCodeField(TableId: Integer; ActivityCodeFieldId: Integer)


$\textbf{🟠\ High\ Severity\ —\ Upgrade}$

IT's UpgradeBusinessActivityCodes() calls CopyBusinessActivityCodeField(TableId, ActivityCodeFieldId) for 25 tables, and the helper hard-codes the destination field number to 12189 (DataTransfer.AddFieldValue(ActivityCodeFieldId, 12189)). Only "Periodic VAT Settlement Entry" actually defines field 12189 as "Business Activity Code". Verified: "General Ledger Setup", "VAT Setup", "VAT Statement Line", and "VAT Statement Name" do not define field 12189 at all in this diff (their new field is 395, and for VAT Setup/Statement Line/Name it isn't even the same field: 395 there is "Per Business Activity Code Settl. Entry" (Boolean) or "Business Activity Code Filter", not a plain code copy target). Calling DataTransfer.CopyFields() against a nonexistent destination field 12189 will fail at runtime for these tables, breaking the IT upgrade path; the remaining ~20 tables that do use field 395 for "Business Activity Code" will silently copy into field 12189 (also nonexistent there), so no upgraded company gets its data migrated into the real field 395.

Knowledge:

microsoft/knowledge/upgrade/datatransfer-for-bulk-init.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T14:31:20Z

+    begin
+        if Code = '' then
+            exit;
+


$\textbf{🟠\ High\ Severity\ —\ Events}$

The new publisher OnGetValidator (internal IntegrationEvent in Business Activity Code Mgt.) uses an ad-hoc name that doesn't encode its position relative to the host procedure Validate, so subscribers cannot tell from the name alone that it fires before dispatch/validation. Rename the publisher (and its IT event subscriber) to an OnBefore.../OnAfter... shape that reflects where it fires within Validate.

Knowledge:

microsoft/knowledge/events/name-events-by-publisher-position.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T14:31:22Z

            Editable = false;
            FieldClass = FlowField;
        }
+        field(395; "Business Activity Code"; Code[10])


$\textbf{🟠\ High\ Severity\ —\ Privacy}$

The PR adds roughly 150+ new 'Business Activity Code' (Code[10]) fields across W1 and country-layer journal, document, archive, history, VAT, and company tables (for example src/Layers/W1/BaseApp/Sales/Document/SalesHeader.Table.al, .../Purchases/Document/PurchaseHeader.Table.al, and .../Finance/GeneralLedger/Journal/GenJournalLine.Table.al) without a DataClassification property. These fields default to ToBeClassified, leaving new business/customer data unreviewed for GDPR/telemetry purposes across dozens of shipped tables in one PR.

Knowledge:

microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md

microsoft/knowledge/privacy/table-level-data-classification-cascades.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T14:31:24Z

$\textbf{🟡\ Medium\ Severity\ —\ Style}$

The changed file src/Layers/IT/BaseApp/Permissions/local.permissionset.al does not follow the ..al convention: both the object segment (local) and the type segment (permissionset) are lower-cased, hurting discoverability by tooling.

Knowledge:

microsoft/knowledge/style/file-name-object-type-pattern.md

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T14:31:25Z

$\textbf{🟡\ Medium\ Severity\ —\ Style}$

The changed file src/Layers/IT/BaseApp/Permissions/localread.permissionset.al does not follow the ..al convention: both the object segment (localread) and the type segment (permissionset) are lower-cased.

Knowledge:

microsoft/knowledge/style/file-name-object-type-pattern.md

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T14:31:26Z

$\textbf{🟡\ Medium\ Severity\ —\ Style}$

The changed file src/Layers/IT/BaseApp/Service/Local/History/ServiceInvoiceHeaderIT.tableExt.al uses a lower-cased type suffix (tableExt) instead of the canonical TableExt segment required by the ..al pattern.

Knowledge:

microsoft/knowledge/style/file-name-object-type-pattern.md

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T14:31:27Z

microsoft/knowledge/style/xmldoc-for-public-library-procedures.md

+
+codeunit 12102 "Business Activity Code Mgt."
+{
+    procedure Validate(Code: Code[10])


$\textbf{🟡\ Medium\ Severity\ —\ Style}$

The new 'Business Activity Code Mgt.' codeunit exposes a public Validate procedure without XML documentation. Add ///
and /// comments describing the contract and behavior for consumers of this new reusable entry point.

Knowledge:

microsoft/knowledge/style/xmldoc-for-public-library-procedures.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

Co-authored-by: Alexander-Ya <179119309+Alexander-Ya@users.noreply.github.com>

…://github.com/microsoft/BCApps into bugs/Implement-Business-Activity-Code-from-IT

github-actions · 2026-08-13T19:50:52Z

$\textbf{🟡\ Medium\ Severity\ —\ Breaking\ Changes}$

Table 12136 "Periodic VAT Settlement Entry" adds the replacement field "Business Activity Code", but the shipped field 1 "Activity Code" remains live with no ObsoleteState, ObsoleteReason, or ObsoleteTag. Keep the original field readable and mark it Pending so dependent extensions get the standard deprecation window before CLEAN29 cleanup.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

        field(1; "Activity Code"; Code[6])
        {
            Caption = 'Activity Code';
            ObsoleteReason = 'Replaced by the Business Activity Code field.';
            ObsoleteState = Pending;
            ObsoleteTag = '29.0';
        }

Knowledge:

microsoft/knowledge/breaking-changes/obsolete-table-fields-instead-of-deleting-them.md

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T19:50:53Z

+        field(12189; "Business Activity Code"; Code[10])
+        {
+            Caption = 'Business Activity Code';
+        }


$\textbf{🟡\ Medium\ Severity\ —\ Data\ Modeling}$

The new "Business Activity Code" field on "Periodic VAT Settlement Entry" lacks TableRelation = "Business Activity".Code even though every other new "Business Activity Code" field in this PR carries that relation. This drops lookup/validation for the field and allows codes that do not exist in table 395.

Suggested change

field(12189; "Business Activity Code"; Code[10])

{

Caption = 'Business Activity Code';

}

field(12189; "Business Activity Code"; Code[10])

{

Caption = 'Business Activity Code';

TableRelation = "Business Activity".Code;

}

_{Agent judgement — not directly backed by a BCQuality knowledge article.}

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T19:50:55Z

            Editable = false;
            FieldClass = FlowField;
        }
+        field(395; "Business Activity Code"; Code[10])


$\textbf{🟠\ High\ Severity\ —\ Privacy}$

The PR adds 179 new Normal "Business Activity Code" fields across changed tables/tableextensions without a field-level DataClassification, relying on table scope instead. BCQuality's AS0016 guidance requires every Normal field to declare DataClassification explicitly rather than inheriting it from the table.

Knowledge:

microsoft/knowledge/privacy/table-level-data-classification-cascades.md

microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T19:50:57Z

    end;

+#if not CLEAN29
+    local procedure UpgradeBusinessActivityCodes()


$\textbf{🟡\ Medium\ Severity\ —\ Telemetry}$

UpgradeBusinessActivityCodes() introduces a one-time migration that creates Business Activity rows and bulk-copies the new field into many tables, but it emits no Session.LogMessage telemetry before setting the upgrade tag, leaving no upgrade-time observability for whether it ran and how much data it moved. Add explicit upgrade telemetry for this procedure (at minimum a stable event id plus success/skip/failure context and migrated row counts) before the upgrade tag is set.

_{Agent judgement — not directly backed by a BCQuality knowledge article.}

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-13T19:50:59Z

    end;

+#if not CLEAN29
+    local procedure UpgradeBusinessActivityCodes()


$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The new validator paths are exercised in src/Layers/IT/Tests/Local/ITActivityCode.Codeunit.al, but this PR also adds UpgradeBusinessActivityCodes() plus 24 CopyBusinessActivityCodeField() migrations and none of the changed test files seeds legacy Activity Code data or verifies that the upgrade both creates Business Activity rows and copies old field values into the new Business Activity Code fields. Add an upgrade test that runs the upgrade against pre-upgrade data and asserts both the table migration and the DataTransfer-based field copy — this would also have caught the field-id mismatch bug found elsewhere in this review.

_{Agent judgement — not directly backed by a BCQuality knowledge article.}

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

github-actions · 2026-08-14T14:30:23Z

        GroupSettlement: Boolean;
        ExceptionalEvent: Boolean;
-        InvalidActivityCodeFilterErr: Label 'The Activity Code Filter should contain exactly one Activity Code.';
+        InvalidActivityCodeFilterErr: Label 'The Business Activity Code Filter should contain exactly one Business Activity Code.';


$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

InvalidActivityCodeFilterErr was reworded to always say "The Business Activity Code Filter should contain exactly one Business Activity Code.", but the still-active #if not CLEAN29 legacy branch (lines ~483-490) reuses the same label when validating the old "Activity Code Filter". A customer still on the legacy path who enters an invalid Activity Code Filter will see an error telling them to fix the Business Activity Code Filter instead, which is confusing and points at the wrong field.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-14T14:30:25Z

+        CompanyInformation.Get();
+        OnGetValidator(CompanyInformation."Country/Region Code", BusinessActivityValidator, IsHandled);
+        if not IsHandled then


$\textbf{🟡\ Medium\ Severity\ —\ Events}$

The new OnGetValidator override seam passes var IsHandled into the publisher without resetting it immediately before the raise. Per BCQuality guidance, add IsHandled := false; before calling the event so fallback validator selection stays deterministic and self-documenting even though the variable is freshly declared here.

Suggested change

CompanyInformation.Get();

OnGetValidator(CompanyInformation."Country/Region Code", BusinessActivityValidator, IsHandled);

if not IsHandled then

CompanyInformation.Get();

IsHandled := false;

OnGetValidator(CompanyInformation."Country/Region Code", BusinessActivityValidator, IsHandled);

if not IsHandled then

Knowledge:

microsoft/knowledge/events/initialize-ishandled-to-false-before-publishing.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-14T14:30:26Z

+        DataTransfer: DataTransfer;
+    begin
+        DataTransfer.SetTables(TableId, TableId);
+        DataTransfer.AddFieldValue(ActivityCodeFieldId, 12189);


$\textbf{🔴\ Critical\ Severity\ —\ Upgrade}$

UpgradeBusinessActivityCodes() hard-codes the DataTransfer destination field as 12189 in CopyBusinessActivityCodeField() for every one of its 24 call sites (Gen. Journal Line, Sales Header, Purchase Header, Company Information, VAT Entry, Service headers, etc.). Verified against the checkout: field 12189 exists only on "Periodic VAT Settlement Entry" (as "Business Activity Code"); none of the other 23 target tables have a field 12189 at all (the new field added by this PR on those tables is 395 "Business Activity Code"). DataTransfer.AddFieldValue with a destination field number that does not exist on the table will fail at runtime, so UpgradeBusinessActivityCodes() will error out on the first non-"Periodic VAT Settlement Entry" table it processes, the upgrade tag is never set, and none of the legacy "Activity Code" values are migrated into the new "Business Activity Code" field for existing customers. This blocks upgrade to this version for any company with Activity Code data.

Knowledge:

microsoft/knowledge/upgrade/datatransfer-for-bulk-init.md

microsoft/knowledge/upgrade/obsolete-pending-to-removed-staging.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T10:56:16Z

                    ApplicationArea = Basic, Suite;
                    Visible = false;
                }
+#if not CLEAN29


$\textbf{🟡\ Medium\ Severity\ —\ Accessibility}$

In roughly 30 IT page files, the obsolete 'Activity Code' field is wrapped in '#if not CLEAN29', but the new 'Business Activity Code' field is added immediately after '#endif' with no corresponding hide/gate. In non-CLEAN29 builds, both controls render together, which creates duplicate, confusing UI for the same concept. Keep only one of these controls visible per build/runtime path.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T10:56:17Z

+        field(395; "Business Activity Code Filter"; Code[10])
+        {
+            Caption = 'Business Activity Code Filter';
+            TableRelation = "Business Activity".Code;
+        }


$\textbf{🟡\ Medium\ Severity\ —\ Data\ Modeling}$

The new 'Business Activity Code Filter' field on VAT Statement Line (W1) is modeled as a normal stored field instead of a FlowFilter. This table already uses FlowFilters for report-time filtering, and the IT layer's version of the same field is marked FlowFilter. Without FieldClass = FlowFilter, the value is stored as data rather than behaving as a transient filter; mark it as a FlowFilter.

Suggested change

field(395; "Business Activity Code Filter"; Code[10])

{

Caption = 'Business Activity Code Filter';

TableRelation = "Business Activity".Code;

}

field(395; "Business Activity Code Filter"; Code[10])

{

Caption = 'Business Activity Code Filter';

FieldClass = FlowFilter;

TableRelation = "Business Activity".Code;

}

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T10:56:18Z

$\textbf{🟡\ Medium\ Severity\ —\ Data\ Modeling}$

The new 'Business Activity Code Filter' field on VAT Statement Name (W1) is modeled as a normal stored field instead of a FlowFilter. In this table, filter fields such as 'Date Filter' are FlowFilters, and the IT layer's own version of this same field correctly marks it FieldClass = FlowFilter. Leaving it as a stored field can persist filter state as data and break expected filter semantics; add FieldClass = FlowFilter.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

        field(395; "Business Activity Code Filter"; Code[10])
        {
            Caption = 'Business Activity Code Filter';
            FieldClass = FlowFilter;
            TableRelation = "Business Activity".Code;
        }

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T10:56:20Z

        ServHeader2."Shortcut Dimension 1 Code" := ServContract2."Shortcut Dimension 1 Code";
        ServHeader2."Shortcut Dimension 2 Code" := ServContract2."Shortcut Dimension 2 Code";
        ServHeader2."Dimension Set ID" := ServContract2."Dimension Set ID";
+        ServHeader2."Business Activity Code" := ServContract2."Business Activity Code";


$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

ServContractManagement copies 'Business Activity Code' into 'Service Header' with := immediately after validating 'Location Code'. Because the target field relies on TableRelation = "Business Activity".Code and has no OnValidate, this bypasses lookup validation and gives the user no error if the contract carries a deleted or programmatically-seeded invalid code. Use Validate("Business Activity Code", ...) here (and on the analogous second assignment in this codeunit) so the copy fails fast.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T10:56:22Z

            Caption = 'Use Concurrent Posting';
            ToolTip = 'Specifies whether to use concurrent posting when posting journals. Concurrent posting can reduce the time it takes to post journals by allowing multiple batches to be posted at the same time. Enabling this option requires additional configuration and setup, such as setting up a batch job to run the concurrent posting process and ensuring that your system has the necessary resources to support concurrent processing.';
        }
+        field(395; "Use Business Activity Code"; Boolean)


$\textbf{🟡\ Medium\ Severity\ —\ Privacy}$

The PR also adds 15 new stored Boolean setup fields without field-level DataClassification (14 'Use Business Activity Code' fields plus BE VAT Setup's 'Per Business Activity Code Settl. Entry'). These are Normal fields, so relying on table-level classification leaves the new settings unresolved instead of explicitly classifying them for release.

Knowledge:

microsoft/knowledge/privacy/table-level-data-classification-cascades.md

microsoft/knowledge/privacy/resolve-tobeclassified-before-release.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T10:56:23Z

@@ -1,4 +1,4 @@
-// ------------------------------------------------------------------------------------------------
+// ------------------------------------------------------------------------------------------------


$\textbf{🟡\ Medium\ Severity\ —\ Style}$

The PR mixes a broad UTF-8 BOM cleanup into the Business Activity Code feature: dozens of IT files change only the file header from '-//' to '+//' in addition to the functional edits. That encoding-only churn is unrelated to the feature, makes the review noisier, and should be reverted or moved to a separate cleanup commit.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T10:56:24Z


        CurrencyCodeHandled := false;
-        OnPostVendorBillLineOnBeforeValidateCurrencyCode(GenJnlLine,VendorBillHeader,VendorBillLine,VendLedgEntry,Bill,AmountLCY,CurrencyCodeHandled);
+        OnPostVendorBillLineOnBeforeValidateCurrencyCode(GenJnlLine, VendorBillHeader, VendorBillLine, VendLedgEntry, Bill, AmountLCY, CurrencyCodeHandled);


$\textbf{🟡\ Medium\ Severity\ —\ Style}$

A few files also fold in one-off formatting-only edits that are unrelated to the new Business Activity Code flow, for example argument-spacing cleanup and indentation fixes in VendorBillListPost.Codeunit.al and FinanceChargeMemoHeader.Table.al. Split or revert these mechanical whitespace changes so the feature diff stays focused on the actual behavior change.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T10:56:25Z

        ServHeader2."Shortcut Dimension 1 Code" := ServContract2."Shortcut Dimension 1 Code";
        ServHeader2."Shortcut Dimension 2 Code" := ServContract2."Shortcut Dimension 2 Code";
        ServHeader2."Dimension Set ID" := ServContract2."Dimension Set ID";
+        ServHeader2."Business Activity Code" := ServContract2."Business Activity Code";


$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The PR adds 'Business Activity Code' propagation in ServContractManagement, but the changed test files only cover IT activity-code/VAT-settlement scenarios and cloud-migration metadata; none exercises the service-contract flow that creates a Service Header from a Service Contract Header. Add a regression test that creates a service contract with a business activity code, runs the two creation paths touched here, and asserts the generated service document preserves the same code, so future refactors cannot silently drop it.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T10:56:27Z

+        DataTransfer.AddFieldValue(ActivityCodeFieldId, 12189);
+        DataTransfer.UpdateAuditFields := false;
+        DataTransfer.CopyFields();
+    end;


$\textbf{🔴\ Critical\ Severity\ —\ Upgrade}$

UpgradeBaseApp.Codeunit.al's new UpgradeBusinessActivityCodes routine calls CopyBusinessActivityCodeField(TableId, ActivityCodeFieldId) for 24 tables (Gen. Journal Line, Purchase Header, VAT Entry, Sales Header, service tables, etc.), and that helper hard-codes the DataTransfer destination field id as 12189. But the new 'Business Activity Code' field was added to all of these BaseApp tables as field 395 (see e.g. src/Layers/W1/BaseApp/Finance/GeneralLedger/Journal/GenJournalLine.Table.al); field id 12189 only exists on the IT-local 'Periodic VAT Settlement Entry' table. On upgrade, DataTransfer.CopyFields() will therefore either fail (field 12189 does not exist on these tables) or silently write into the wrong destination field, so the intended migration of existing Activity Code data into Business Activity Code is broken for every table except Periodic VAT Settlement Entry.

Knowledge:

microsoft/knowledge/upgrade/datatransfer-for-bulk-init.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T14:27:19Z

+// ------------------------------------------------------------------------------------------------
+namespace Microsoft.Foundation.AuditCodes;
+
+table 395 "Business Activity"


$\textbf{🔴\ Critical\ Severity\ —\ AppSource}$

The new Business Activity feature adds a setup/list page and lookup-backed fields in the app's own UI, but the diff only grants tabledata "Business Activity" in the IT LOCAL/LOCAL READ permission sets (src/Layers/IT/BaseApp/Permissions/local.permissionset.al and localread.permissionset.al). No W1/BaseApp permission set grants tabledata "Business Activity", so standard non-SUPER users outside Italy can hit missing-permission failures when setting up or using this feature (e.g. via the new "Business Activities" list page or the TableRelation lookup from any document header).

Knowledge:

microsoft/knowledge/appsource/permission-sets-cover-setup-and-usage-without-super.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T14:27:22Z

+
+        asserterror BusinessActivityCode.Validate(Code, '1234567');
+
+        Assert.ExpectedError('cannot be longer than 6 characters in Italy');


$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The new negative test verifies that an error occurred, but it hardcodes the expected message text inline instead of asserting through a shared Label or helper. That makes the test brittle to wording/localization changes and weakens the reusable error contract the guidance recommends for asserterror checks.

Knowledge:

microsoft/knowledge/testing/asserterror-needs-expectederror-and-code.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T16:36:33Z

        {
            Caption = 'Activity Code';
        }
+        field(12189; "Business Activity Code"; Code[10])


$\textbf{🟡\ Medium\ Severity\ —\ Data\ Modeling}$

"Periodic VAT Settlement Entry" is the only exact "Business Activity Code" table-field addition in this PR that does not follow the common shape used elsewhere: it uses field number 12189 instead of 395 and adds no TableRelation = "Business Activity".Code (it also relies on table-level DataClassification rather than a field-level one). That makes this rollout inconsistent with the rest of the PR and removes lookup/validation on the new code field; it also explains why the upgrade codeunit's hardcoded destination field 12189 happens to work only for this one table.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

field(12189; "Business Activity Code"; Code[10]) { Caption = 'Business Activity Code'; DataClassification = CustomerContent; TableRelation = "Business Activity".Code; }

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T16:36:36Z

            Caption = 'Use Concurrent Posting';
            ToolTip = 'Specifies whether to use concurrent posting when posting journals. Concurrent posting can reduce the time it takes to post journals by allowing multiple batches to be posted at the same time. Enabling this option requires additional configuration and setup, such as setting up a batch job to run the concurrent posting process and ensuring that your system has the necessary resources to support concurrent processing.';
        }
+        field(395; "Use Business Activity Code"; Boolean)


$\textbf{🟠\ High\ Severity\ —\ Privacy}$

14 changed "General Ledger Setup" table copies (APAC, BE, CH, DACH, ES, FR, GB, IT, NA, NL, NO, RU, SE, W1) add a Normal "Use Business Activity Code" field without field-level DataClassification. Privacy guidance requires every Normal table field to declare DataClassification explicitly.

Knowledge:

microsoft/knowledge/privacy/table-level-data-classification-cascades.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T16:36:37Z

        {
            Caption = 'Ship-To Alt. Cust. VAT Reg.';
        }
+        field(395; "Per Business Activity Code Settl. Entry"; Boolean)


$\textbf{🟠\ High\ Severity\ —\ Privacy}$

The new "Per Business Activity Code Settl. Entry" field on BE's VATSetup.Table.al is a Normal field added without field-level DataClassification. Privacy guidance requires every Normal table field to declare DataClassification explicitly.

Knowledge:

microsoft/knowledge/privacy/table-level-data-classification-cascades.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

github-actions · 2026-08-15T16:36:38Z

$\textbf{🟠\ High\ Severity\ —\ Privacy}$

The new "Business Activity Code Filter" fields on IT's VATStatementLine.Table.al and VATStatementName.Table.al are Normal fields added without field-level DataClassification. Privacy guidance requires every Normal table field to declare DataClassification explicitly.

Knowledge:

microsoft/knowledge/privacy/table-level-data-classification-cascades.md

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.33.4}

Alexander Yakunin (Alexander-Ya) added 3 commits August 13, 2026 14:26

Implement Business Activity Code from IT to W1

59b2ac4

Merge branch 'main' of https://github.com/microsoft/BCApps into bugs/…

51d8d45

…Implement-Business-Activity-Code-from-IT

Propagate changes

083ad87

Alexander Yakunin (Alexander-Ya) requested review from a team August 13, 2026 13:35

Alexander Yakunin (Alexander-Ya) deployed to triage August 13, 2026 13:35 — with GitHub Actions Active

github-actions Bot added Other GitHub request for other area than SCM, Finance or Integration Ownership: Needs Review Ownership is Other, low confidence, or needs manual correction labels Aug 13, 2026

github-actions Bot reviewed Aug 13, 2026

View reviewed changes

Add missing APAC change

47b5a9c

github-actions Bot reviewed Aug 13, 2026

View reviewed changes

Copilot started work on behalf of Alexander Yakunin (Alexander-Ya) August 13, 2026 18:12 View session

Fix AL0792 unused usings breaking Apps AT build

4cd164d

Co-authored-by: Alexander-Ya <179119309+Alexander-Ya@users.noreply.github.com>

Copilot finished work on behalf of Alexander Yakunin (Alexander-Ya) August 13, 2026 18:18

github-actions Bot added needs-approval Workflow runs require maintainer approval to start and removed needs-approval Workflow runs require maintainer approval to start labels Aug 13, 2026

Alexander Yakunin (Alexander-Ya) added 2 commits August 13, 2026 21:32

Fix compile errors

f6def32

Merge branch 'bugs/Implement-Business-Activity-Code-from-IT' of https…

5bd6b69

…://github.com/microsoft/BCApps into bugs/Implement-Business-Activity-Code-from-IT

github-actions Bot reviewed Aug 13, 2026

View reviewed changes

Update solution

98068b0

github-actions Bot reviewed Aug 14, 2026

View reviewed changes

Add missing change

740803f

github-actions Bot reviewed Aug 15, 2026

View reviewed changes

Fix warnings and errors

84ff489

github-actions Bot reviewed Aug 15, 2026

View reviewed changes

Fix VAT Statement Line

6c4f41b

github-actions Bot reviewed Aug 15, 2026

View reviewed changes

		@@ -1,4 +1,4 @@
		// ------------------------------------------------------------------------------------------------
		// ------------------------------------------------------------------------------------------------


		asserterror BusinessActivityCode.Validate(Code, '1234567');

		Assert.ExpectedError('cannot be longer than 6 characters in Italy');

Uh oh!

Conversation

Alexander Yakunin (Alexander-Ya) commented Aug 13, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What & why

Linked work

How I validated this

Risk & compatibility

Uh oh!

github-actions Bot commented Aug 13, 2026

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 13, 2026

Uh oh!

github-actions Bot commented Aug 13, 2026

Uh oh!

github-actions Bot commented Aug 13, 2026

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 13, 2026

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 14, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 14, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 14, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 15, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 15, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 15, 2026

Uh oh!

github-actions Bot Aug 15, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 15, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 15, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 15, 2026

Choose a reason for hiding this comment

Alexander Yakunin (Alexander-Ya) commented Aug 13, 2026 •

edited by github-actions Bot

Loading